@wpferguson : Can you double check this. TIA.

I saw this last night, but didn't realize that it was my change that caused it. When I went to find the problem, I couldn't reproduce. Testing now....

I still see it on tif, dng, and a cr3. I'll do some digging....

Another datapoint, opened a skull image in darkroom and it's fine, but the filmstrip thumbnails are all skulls

I backed up before my change and loaded some tif's with -d imageio -d cache

Here's part of the log...

     7.1830 [tiff_open] 3089x2048 8bpp, 3 samples per pixel.
     7.1888 [tiff_open] 3089x2048 8bpp, 3 samples per pixel.
     7.1892 [tiff_open] 3089x2048 8bpp, 3 samples per pixel.
     7.1898 [tiff_open] 2545x3393 16bpp, 3 samples per pixel.
     7.1902 [tiff_open] 1729x1729 16bpp, 3 samples per pixel.
     7.1906 [tiff_open] 4816x3219 16bpp, 4 samples per pixel.
     7.2731 [dt_imageio_export_with_flags]  modules: colorin colorout gamma
     7.2731 [dt_imageio_export] thumbnail imgid 38474, 3089x2048 --> 1357x900 (scale=0.4395, maxscale=1.0000). upscale=no, hq=no
     7.2785 [dt_imageio_export_with_flags]  modules: colorin colorout gamma
     7.2786 [dt_imageio_export] thumbnail imgid 38475, 3089x2048 --> 1357x900 (scale=0.4395, maxscale=1.0000). upscale=no, hq=no
     7.3014 [dt_imageio_export_with_flags]  modules: colorin colorout gamma
     7.3014 [dt_imageio_export] thumbnail imgid 38476, 3089x2048 --> 1357x900 (scale=0.4395, maxscale=1.0000). upscale=no, hq=no
     7.3149 [dt_imageio_export_with_flags]  modules: colorin colorout gamma
     7.3149 [dt_imageio_export] thumbnail imgid 38477, 2545x3393 --> 675x900 (scale=0.2653, maxscale=1.0000). upscale=no, hq=no
     7.3184 [mipmap_cache] generate mip 3 for ID=38474 from scratch
     7.3191 [tiff_open] 4816x3219 8bpp, 4 samples per pixel.
     7.3322 [mipmap_cache] generate mip 3 for ID=38475 from scratch
     7.3340 [tiff_open] 2550x3300 8bpp, 3 samples per pixel.
     7.3431 [mipmap_cache] generate mip 3 for ID=38476 from scratch

trying to trace the execution to see how we get from tiff open to dt_imageio_export

The problem seems to be in dt_imageio_large_thumbnail but I haven't figured out what it is or how to solve it.

Unless you have an idea, I would say revert my PR and I'll work on it until I solve the problems. At least that way it wont affect people trying to use master.

For me the fix works, at least for NEF and DNG

@AndDiSa : Indeed, it works for RAW & JPEG but still buggy for TIFF.

@wpferguson : I have pushed the revert I had prepared.

After a nights sleep and some time to think this is what I came up with.

The original problem was that dt_imageio_export_with_flags is a gboolean returning "backwards" indicators. dt_imageio_export_with_flags used to return an int, 0 for success and 1 for error which is standard. Nothing downstream uses dt_imageio_export_with_flags as a boolean and all the downstream code still treats it as returning an int.

So, I propose simply turning dt_imageio_export_with_flags back into an int and let it return 0 and 1. The sanity crowd is happy because the return value is standard, and almost no code needs to be changed (I'll look at the Lua stuff).

As for dt_imageio_large_thumbnail I'm still going to play with this and see if I can at least understand the coupling between it and the mipmap_cache code. I'm starting to suspect that the real issue may be the mipmap_cache not asking (or not asking correctly) for the thumbnail.

Thanks for cleaning up my mess.

@wpferguson : No problem, I spend quite some time trying to fix the issue but could not either... One data point:

In dt_imageio_large_thumbnail we have (in this PR):

gboolean dt_imageio_large_thumbnail(const char *filename,
                                    uint8_t **buffer,
                                    int32_t *width,
                                    int32_t *height,
                                    dt_colorspaces_color_profile_type_t *color_space)
{
  int res = TRUE;

So res to TRUE, and some early return:

  // get the biggest thumb from exif
  if(dt_exif_get_thumbnail(filename, &buf, &bufsize, &mime_type))
    goto error;

But the goto error here is misleading, a whole mess :( This is not an error as we exit with 1 (TRUE) !!!

I tried fixing that but the last state of this PR is ok for everything expect TIFF.

I would say that we want to continue to work on this... We need to fix for a better future :)

Maybe I should change my username to Pandora :-D

I would say that we want to continue to work on this... We need to fix for a better future :)

I agree. My brain segfaulted a few times trying to make sense of the code. I'll keep playing with it. I enjoy puzzles

Good, start over this PR which has already quite some fixes.

@wpferguson : I have just pushed a new version with your changes and mine on top. Let's play :)